Thus non-repudiation of origin implies message authentication, which in turn implies message integrity.
Corresponding to non-repudiation of origin, the recipient may return a message, secured by a digital signature, which provides non-repudiation of receipt. Of a different nature is the service confidentiality, which protects against disclosure of the content of a message during transit over some network.
UN/EDIFACT security is concerned with the protection of the EDIFACT messages only, and not the internal security related to the end-user applications, where the messages are being generated or processed. In conclusion, the use of security in UN/EDIFACT requires the use of cryptographic techniques, which in turn require the use of cryptographic keys. Thus key management is implied by the use of security in UN/EDIFACT.
For all security purposes, keys (which in fact are large numbers) must be treated with care. Algorithms are in general public knowledge, and only give the desired security if combined with keys. The users may have a common key which is used for cryptographic purposes, or they may each have a pair of matching keys (one private and one public key). Common to all systems are that keys must be distributed in a secure manner. This may either be handled on a bilateral basis, or by involving a third party. The third party is trusted to handle certain procedures regarding registration, certification and distribution of keys. These third parties are often called Trusted Third Parties (TTPs). Under all circumstances there must be agreed rules and procedures for key management between the involved parties.
Additional Security Procedures and Services. To respond fully to the various risks associated with electronic data interchange, parties may wish to consider, as to some of the following risks, implementing some of the following procedures and services, which are independent of the UN/EDIFACT structure:
- the use of additional identification codes, unique sequence codes or similar non-encrypted tracing and labelling schemes;
- employing value-added third party service providers to record message transaction logs or similarly archive or verify transaction activity;
- using protected automatic storage on local work stations within a company's computer network; and
- monitoring the availability and integrity of communication facilities.
2.6. Record Storage
"The parties shall store and retain records and the Messages communicated under this Agreement as may be specified in the Technical Annex."
Relevant details and specifications regarding the storage and retention of records and the Messages might include:
- the range of records to be maintained
- the format(s) in which storage is to made
- time periods for which records are to be retained
- the media to be used for the storage and retention
- the rights of access to the records to be provided
- the manner in which storage will be maintained (including testing, environmental conditions and the like)
- requirements for integrity and irreversibility of the records
- the rules relating to the availability of the records.
Parties are encouraged to consider, in responding to this item, the details specified in response to Section 2.5, Security Procedures and Services.
SECTION 3: MESSAGE PROCESSING
3.1. Receipt
"Any Message transmitted in compliance with this Agreement shall be deemed received when accessible to the receiving party in the manner designated in the Technical Annex."
Designation of the manner of accessibility could include:
- accessibility through a service provider acting on behalf of the receiver
- accessibility by the receiver to the Message as stored by a service provider (in an electronic mailbox, for example)
- accessibility through the internal computer system of the receiver.
3.2.1. Acknowledgement
"Unless otherwise designated in the Technical Annex, the receipt of a Message need not be acknowledged by the receiving party. A requirement for acknowledgement in the Technical Annex shall include the methods and types of acknowledgements (including any Messages or procedures) and the time periods, if any, in which acknowledgement must be received"
Parties may designate when acknowledgement is to be required in more than one manner. Messages to be acknowledged may be specified by message type (for example, by using the UN/EDIFACT Message names) or by specifying the circumstances in which transmitted Messages require acknowledgement. Parties may wish to specify that acknowledgement is required when requested in the Message that has been transmitted.
When acknowledgement is to be required, the parties should also specify the details regarding how the acknowledgement is to be provided, including:
